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Background 

Field of the Invention 

[0002] The present invention relates in general to securities trading and in particular 
to electronic commerce marketplaces and order management systems for supporting 
securities trading. 

Background Art 

[0003] Although computers are heavily used to facilitate trading of securities, manual 
intervention is still required at certain steps in the trading process. For example, most 
traders at institutional investment management firms record their orders to purchase or 
sell securities in computerized order management systems (OMS's). However, one or 
more traders at each firm must manually review the orders in the OMS and attempt to fill 
the orders by contacting one or more market intermediaries. Typically, the traders 
transmit the orders in the OMS by telephone or separate data entry links to registered 
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broker-dealers for the securities, to electronic marketplaces that trade the securities, or to 
other market intermediaries. Accordingly, manual effort is required to actually execute 
the orders in the OMS. 

[0004] One problem arising from this manual effort is that institutional traders cannot 
execute trades involving large quantities of securities without adversely affecting the 
market price of the securities. For example, institutional traders often need to trade large 
quantities of securities due to the continuing need of investment managers to respond to 
changes in market conditions by altering the contents of their investment portfolios. As 
these portfolios increase in size due to increased investor activity, the corresponding 
quantity of securities to be traded in order to achieve a similar portfolio balance also 
increases. Market impact costs, or adverse costs resulting from the institutional traders' 
activities, rise in such circumstances because locating parties with whom to trade such 
large quantities of securities becomes more difficult for the market intermediaries. 

[0005] Moreover, if the market intermediaries become aware that an institutional firm 
wants to, say, sell a large block of a particular equity security, this awareness is likely to 
lower the sale price that the institutional firm can obtain due to the normal processes of 
supply and demand. The effect is also likely to be exacerbated by speculation from 
others with knowledge of the order as to why the particular investor wishes to sell such a 
large quantity of the security. Similarly, if market intermediaries become aware of the 
fact than an institutional firm wants to buy a large block of a particular equity security, 
this awareness will likely increase the purchase price that the institutional firm will have 
to pay. This adverse effect on price is further exacerbated by the fact that traditional 
market intermediaries trade for their own accounts. 
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[0006] One strategy commonly employed by institutional traders to offset market 
impact costs is to spread out trade orders for a large quantity of a security into small 
orders each handled by a different market intermediary, sometimes over several trading 
days. Of course, this strategy brings about its own problems in that the market price can 
change significantly during this extended trading period due to the unforeseeable 
activities of others. 

[0007] Another strategy that may be employed is to spread the orders for the security 
among one or more electronic marketplaces. However, the traders must manually 
transmit each order to the electronic marketplaces using a telephone or a separate data 
entry link. The fact that the traders need to perform these extra steps, which include 
duplicate entry of basic order data already recorded in the OMS, causes many traders to 
use these electronic marketplaces infrequently, and to supply the marketplaces with only 
a small subset of the total orders. As a result, these electronic marketplaces often lack the 
liquidity required by a trader to timely execute orders. 

[0008] The lack of integration between the OMS and the electronic marketplaces also 
poses problems when an institutional trader wishes to trade a particular security 
simultaneously within an electronic marketplace and, for example, over the telephone 
with a traditional broker. For example, some electronic marketplaces attempt to find 
matches at only specific time intervals. If a trader wishes to buy 100,000 shares of IBM, 
and has placed an order for half that amount in an electronic marketplace, the trader will 
not know how much, if any, IBM stock was purchased until after the next scheduled 
match attempt. In the meantime, the trader potentially could have purchased more than 
50,000 shares from a broker over the phone at a better price. 
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[0009] Therefore, there is a need in the art for an electronic trading marketplace that 
does not require any manual intervention by traders or other parties, offers anonymity, 
and offers a high amount of liquidity. 

Disclosure of the Invention 
[001 0] The present invention addresses the above need by providing for the 
automated transmission of orders (i.e., without manual trader intervention) from the 
various order management systems (OMS's) used by investment management firms or 
other entities having trading systems to an electronic trading marketplace (ETM). A firm 
with a trading system stores information about orders in an OMS to manage its order 
flow, to monitor the initiation, placement, and execution of orders, and for related 
purposes. Software providing the functionality of an OMS is well known in the art. 

[001 1] OMS interfacing modules (OEMs) at the firms automatically transmit orders 
from the OMS's to the ETM and preferably update the OMS's in response to orders 
executed at the ETM. Traders can communicate with the ETM to anonymously negotiate 
trades of securities. As used herein, a "security" is an ownership or creditorship interest, 
such as a stock certificate, bond, or any other financial instrument, contract or 
transaction, such as a forward, futures, option, put, call, collar, swap, or currency contract 
on any security. This description uses the term "security" for convenience but it should 
be understood that the term covers financial instruments generally. 

[001 2] The ETM includes an OMS data integration module (ODIM) for receiving 
and processing data representative of orders received from the OIMs. In a preferred 
embodiment, the data from the OIMs are provided to the ETM in a standardized format 
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that requires little processing by the ODEVL The orders processed by the ODM are 
stored in an ETM database. 

[001 3] A negotiation module in the ETM supports negotiations between traders. In 
one embodiment, an indications module transmits orders received by the ETM among the 
traders based upon filtering criteria established by the traders and/or the ETM. These 
orders are transmitted among the traders in the form of non-binding indications. Based 
upon these indications, traders at one institution can enter into negotiations with traders at 
other institutions, through the negotiation module of the ETM. In one embodiment, at 
least parts of the negotiations are conducted anonymously. 

[001 4] A trader authentication module authorizes and authenticates traders who log 
into the ETM in order to perform trading negotiations and/or other functions. A 
transaction history module records transactions performed by the ETM in the ETM 
database. The transaction history module also preferably records other data processed by 
the ETM including, for example, the orders received from and sent to the trading systems 
and the conducted negotiations. 

[001 5] A typical trading system at an investment management firm or other entity at 
which trading is performed includes a number of workstations coupled to an OMS server 
via a network, with a trader at each workstation. Each workstation preferably executes a 
trader OMS interaction module (TOIM) for facilitating interactions between the trader's 
workstation and the OMS server. In one embodiment of the present invention, the TOIM 
allows a trader to add, delete, or modify open or contemplated orders stored in the OMS 
database. The OMS, which includes the OMS server, OMS database, and TOIM, is 
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typically provided by an OMS vendor, though some firms have developed their own 
OMS's. 

[001 6] In connection with the present invention, each workstation also preferably 
executes an ETM interaction module (EIM) for facilitating interactions with the ETM. 
The EIM allows a trader to send information to the ETM and view and respond to 
information received from the ETM. Typically, this information includes information 
about the trader's indications, information about other traders' indications,. and orders 
transmitted to and received by a trader during a negotiation. 

[0017] The OMS database holds data representative of open, contemplated, or 
completed orders to buy and/or sell securities by traders using the trading system. The 
OIM is in communication with the OMS database and the ETM. An OMS database 
integration module in the OIM reads data records stored in the OMS database and, in a 
preferred embodiment, also creates and modifies data records stored in the OMS database 
upon execution of a trade through the ETM. In one embodiment, the OMS database 
interaction module directly accesses the OMS database and in another embodiment it 
sends commands to an application programming interface (API) in the OMS for 
accessing the database. 

[001 8] The OIM also includes an ETM communication module for communicating 
with the ETM. In one embodiment, the ETM communication module provides selected 
data records in the OMS database to the ETM and, in a preferred embodiment, receives 
data and/or instructions from the ETM regarding changes to make to the OMS database. 
In addition, the OIM preferably includes a data record conversion module for modifying 


6 


22172/05507/SF/5035215.4 


Case 5507 Patent 

the format of data records sent to the ETM and/or received from the ETM. The OM also 
preferably includes a filtering module for filtering out specified orders by security type, 
security name, order type, order price, order quantity, or other category, so that those 
orders are not transmitted to the ETM. 

[001 9] Preferably, the OIM transmits to the ETM data records in the OMS database 
relating to a trader's orders when the trader logs on to the ETM. Once the OIM 
determines that the trader has logged on to the ETM, the OIM retrieves data records 
about that trader's orders suitable for transmission to the ETM from the OMS database. 
In one embodiment, the OIM converts the data records retrieved from the OMS database 
into a standardized format understood by the ETM. In another embodiment, this 
functionality is part of the ETM. 

[0020] After a trader has logged on to the ETM, the OIM determines whether the 
contents of the OMS database have changed. If the OMS database has changed, the OIM 
determines whether the change should be transmitted to the ETM. In one embodiment, 
the OIM continues to determine whether the contents of the OMS database have changed 
between the time that a trader logs on to the ETM and the time that the ETM commences 
trading. In another embodiment, the OM does not commence making this determination 
until the time that the ETM commences trading. 

[0021] Because typical OMS's are complex and multi-featured, and because 
securities of types not handled by the ETM may be traded using the OMS, some changes 
to the OMS database do not necessitate a transmission of updated data to the ETM. The 
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OIM preferably transmits changes to the database to the ETM if the changes represent 
new or modified orders. 

[0022] The OIM preferably updates the database in response to information received 
from the ETM indicating executed trades or other information. In a preferred 
embodiment, if an execution occurred in the ETM involving an order in the OMS 
associated with the OIM, the OIM receives information from the ETM describing the 
execution. This information includes, for example, the type, amount, and price of 
securities traded, the time of execution, and/or information identifying the original order 
in the OMS database on which the execution was based. The OIM converts the received 
information about the execution into the format used by the OMS and updates the OMS 
database accordingly. As a result of these steps, the OMS is updated automatically and 
transparently to reflect executions performed at the ETM. The executions appear to the 
OMS as typical trades conducted at another broker, so no special functionality needs to 
be added to the OMS in order to interact with the ETM beyond that functionality 
described herein. 

Brief Description of the Drawings 
[0023] FIGURE 1 is a high-level block diagram illustrating an electronic trading 
marketplace (ETM) environment according to an embodiment of the present invention; 

[0024] FIGURE 2 is a high-level block diagram illustrating more details of the ETM; 

[0025] FIGURE 3 is a lower-level block diagram illustrating a trading system like 
those illustrated in FIG. 1 ; 
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[0026] FIGURE 4 is a diagram illustrating a data record stored in the order 
management system (OMS) database to identify an order according to one embodiment 
of the present invention; 

[0027] FIGURE 5 is a diagram illustrating a placement record preferably stored in the 
OMS database to indicate a placement of an order at a particular venue; 

[0028] FIGURE 6 is a diagram illustrating an execution record preferably stored in 
the OMS database to indicate the execution of an order; 

[0029] FIGURE 7 is a flow diagram illustrating actions performed by an embodiment 
of the present invention when a trader logs on to the ETM; 

[0030] FIGURE 8 is a flow diagram illustrating actions performed by an embodiment 
of the present invention after a trader has logged on to the ETM; and 

[0031 ] FIGURE 9 is a flow diagram illustrating actions performed by a preferred 
embodiment of the present invention when the OMS database is updated in response to a 
trade executed by the ETM. 

Detailed Description of the Preferred Embodiments 
[0032] FIG. 1 is a high-level block diagram illustrating an electronic trading 
marketplace (ETM) environment according to an embodiment of the present invention. 
An ETM 1 10 is in communication with three trading systems 1 12A, 1 12B, 1 12C. 
Although only three trading systems 1 12 are illustrated, embodiments of the present 
invention can have many more (or fewer) trading systems 1 12 in communication with the 
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ETM 110. FIG. 1 illustrates only three trading systems 1 12 in order to enhance the 
clarity of this description. 

[0033] The trading systems are used by investment management firms or other 
entities that have established a relationship with the ETM 1 10. The trading systems 1 12 
communicate with the ETM 1 10 to facilitate the trading of securities. As used herein, a 
"security" is any ownership or creditorship interest, such as a stock certificate or bond, or 
any other financial instrument, contract, or transaction, such as a forward, futures, option, 
put, call, collar, swap, or currency contract. This definition includes, for example, any 
note, stock, bond, debenture, certificate of interest or participation in any profit-sharing 
agreement or in any oil, gas, or other mineral royalty or lease, any collateral trust 
certificate, investment contract, voting-trust certificate, certificate of deposit, any put, 
call, straddle, option, or privilege on any of the foregoing, or group or index of securities 
(including any interest therein or based on the value thereof). This list is not all- 
inclusive. For purposes of clarity, this description will describe the trading of stock. 

[0034] Within each trading system 1 12 is a database 1 14A, 1 14B, 1 14C associated 
with an order management system (OMS). Each OMS database 1 14 holds data 
representative of open, contemplated, or completed orders to buy and/or sell securities 
(collectively referred to herein as "orders for securities") by traders using the trading 
system 1 12. For example, assume that the database 1 14A of trading system 1 12A 
contains orders to sell 50,000 shares of DELL and 75,000 shares of MSFT and orders to 
buy 25,000 shares of CPQ and 100,000 shares of IBM. Also assume that the database 
1 14B of trading system 1 12B contains orders to sell 30,000 shares of CPQ and buy 
62,000 shares ofT. 
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[0035] The orders in the OMS databases 1 14 are automatically transmitted to the 
ETM 110. Likewise, any changes in the orders, such as modifications and/or 
withdrawals, are automatically transmitted to the ETM 110. As used herein, the term 
"automatically" means that the associated action is performed without any human or 
manual intervention. Thus, there is no need for traders to specifically request that 
individual orders in the OMS databases 1 14 are transmitted to the ETM 110; orders in the 
databases are sent to the ETM 1 10 without the traders' input (subject to filtering criteria). 

[0036] Preferably, the ETM 110 anonymously transmits information about a trader's 
orders to other traders using the ETM, subject to filtering in accordance with filtering 
criteria established by the traders and/or the ETM. Moreover, the ETM 110 preferably 
manages anonymous negotiations between traders using the trading systems 1 12 for the 
purpose of executing the orders and sends data about the completed trades to the OMS's 
of the traders involved in the transaction. 

[0037] Thus, one embodiment of the present invention selectively broadcasts 
information about the orders received by the ETM 110 from the database 1 14A of trading 
system 1 12A to the other trading systems 1 12B, 1 12C. Likewise, the ETM 110 
selectively broadcasts information about the orders received from the database 1 14B of 
trading system 1 12B to the other trading systems 1 12 A, 1 12C. If the traders desire such a 
trade, the ETM 110 will facilitate the anonymous negotiation and sale of 25,000 shares of 
CPQ from a trader using trading system 1 12B to a trader using trading system 1 12 A. 

[0038] Data is communicated between the trading systems 112 and the ETM 1 10 
using interfacing links 1 16 A, 1 16B, 1 16C. Any known interfacing technologies can be 
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used to effectuate these links, including, but not limited to, transmission control 
protocol/Internet protocol (TCP/IP), satellite, cellular, and/or radio frequency (RF) links, 
or some combination thereof. The links may pass through one or more intermediate data 
processing systems, such as telephone switches or Internet servers, before reaching the 
ETM 1 10 or a trading system 112. In embodiments where data travels over shared links, 
such as embodiments where data travels over the public Internet, the data is preferably 
encrypted using a secure protocol, such as the secure sockets layer (SSL). 

[0039] FIG. 2 is a high-level block diagram illustrating more details of the ETM 110. 
Those of skill in the art will recognize that FIG. 2 illustrates only one possible 
embodiment of the ETM 110. Obviously, different combinations of hardware and 
software can be used to provide the functionality of the ETM 110 described herein. 

[0040] Data received by the ETM 110 from the trading systems 112 over the 
interfacing links 1 16 are received by a firewall 210. As is known in the art, the firewall 
210 preferably prevents unauthorized users from gaining access to the rest of the ETM 
110 and monitors transfers of data to and from the network. 

[0041] Data that pass through the firewall 210 are received by one or more modules 
that perform the functionality of the ETM 110. As used herein, the term "module" refers 
to machine-executable code and/or data, but may also include associated circuitry, such 
as processing circuitry, as well as data storage areas, and/or any other software or 
hardware. Thus, it will be appreciated that one or a combination of hardware and 
software, such as a computer system executing software for performing the functionality 
of the modules, may implement each of the modules shown in FIG. 2. It will also be 
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appreciated by those skilled in the art that the ETM 110 may comprise one or more other 
types of modules, circuitry, etc., not shown in FIG. 2 in order to avoid unnecessarily 
obscuring understanding of the invention. For instance, the ETM 110 may include one or 
more microprocessors, network connection circuitry, and/or data storage areas, such as 
read-only memory (ROM), random-access memory (RAM), CDROM, DVD, tape drive, 
hard disk (HD), and/or other types of storage areas. It will also be appreciated that the 
functionality of multiple modules described herein can be combined into a single module 
and the functionality of a single module can be split or shared among multiple modules. 
Moreover, alternative embodiments of the present invention can lack one or more of the 
modules described herein and/or have modules not described herein. 

[0042] The ETM 110 preferably includes an OMS data integration module (ODIM) 
212. The ODIM 212 receives and processes data representative of orders received from 
the OMS databases 1 14 in the trading systems 112. In a preferred embodiment, the data 
from the OMS databases 1 14 are provided to the ETM 1 10 in a standardized format that 
requires little processing by the ODIM 212. In an alternative embodiment, the data from 
the OMS databases 1 14 are provided to the ETM 1 10 in one or more different formats 
depending upon factors such as the type of OMS used by the trading systems 1 12, the 
types of interfacing links supplying the data to the ETM, the type of security or orders to 
which the data pertains, and the like. In this latter embodiment, the ODIM 212 preferably 
converts the data into a standardized format for use by other modules in the ETM 110. 

[0043] The orders processed by the ODIM 212 are stored in an ETM database 214. 
Data in the database 214 are preferably accessible to the other modules in the ETM 110. 
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In addition, the other modules in the ETM 1 10 can store other data in the illustrated 
database 214 or other databases as may be required during normal operation. 

[0044] In a preferred embodiment, an indications module 216 transmits information 
about orders received by the ETM 110 among the various traders based upon filtering 
criteria established by the traders and/or the ETM. This information is transmitted among 
the traders in the form of non-binding indications. 

[0045] Based upon these indications, traders can enter into negotiations with other 
traders through a negotiation module 218. The negotiation module 218 facilitates 
negotiations between traders using trading systems and having contra interests. In one 
embodiment, at least parts of the negotiations are conducted anonymously, in order to 
limit the spread of information about the traders' activities. 

[0046] A market data module 220 receives real-time and other market data from an 
input 222. The market data module 220 provides the market data to the negotiation 
module 218 and to the traders. The traders preferably use the market data during the 
negotiations to determining market prices for the securities. 

[0047] A transaction history module 224 records transactions performed by the ETM 
1 10 in the database 214. The transaction history module 224 also preferably records 
other data processed by the ETM 110 including, for example, information about orders 
received from and sent to the trading systems 1 12 and the negotiations conducted 
(successful or not). This module 224 is preferably used to audit the transactions 
conducted on the ETM 110. 
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[0048] A trader authentication module 226 authorizes and authenticates traders who 
log into the ETM 1 10 in order to perform trading negotiations and/or other functions. In 
one embodiment, the trader authentication module 226 stores authentication information, 
such as a login ID/password pair in the database 214. The trader authentication module 
226 also preferably stores profiles for the registered traders. 

[0049] Other modules that may be present in the ETM 110 include load monitoring 
modules for monitoring the load on various servers comprising the ETM, fault tolerance 
modules for providing fault tolerance to the ETM, security modules for preventing and 
detecting security violations on the ETM, and back office modules for providing back 
office functionality. These modules are not shown in FIG. 2 in order to avoid 
unnecessarily complicating the figure. 

[0050] FIG. 3 is a lower-level block diagram illustrating a trading system 1 12 like 
those illustrated in FIG. 1 . Those of ordinary skill in the art will recognize that FIG. 3 
illustrates only one possible embodiment of a trading system 112 and alternative 
embodiments of the trading system exist. FIG. 3 illustrates three workstations 31 OA, 
31 0B, 3 10C coupled to an OMS server 312 via a network 314. The workstations 310 are 
preferably general- or specific-purpose computer systems executing specialized software 
for facilitating trading of securities. Although only three workstations 310 are illustrated, 
a trading system 1 12 can have any practical number of workstations. 

[0051 ] In a typical trading system that interacts with the ETM 1 10, each workstation 
310 executes a trader OMS interaction module 316 (TOM) for facilitating interactions 
with the OMS server 312. In this typical trading system, the TOIM 316 allows a trader to 
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add, delete, or modify open or contemplated orders stored in the OMS database 114. 
Contemplated orders may be stored in the OMS database 1 14, for example, because the 
trader intends to execute certain transactions in stages, or because the contemplated 
transactions are desirable only if the market prices of the securities to be traded are within 
a certain range (e.g., limit orders). Therefore, such orders serve as placeholders 
indicating the total quantity of a security that a trader wishes to transact and conditions 
for transacting other orders; other data in the database 1 14 indicate the quantity of the 
security that has been transacted to date. 

[0052] Each workstation 310 executes an ETM interaction module 3 1 8 (EM) for 
facilitating interactions with the ETM 1 10. In alternative embodiments of the present 
invention, the EIM 318 is incorporated into the TOIM 316 or other modules on the 
workstation 310. The EIM 318 allows a trader to send information to the ETM 110 and 
view and respond to information received from the ETM 110. Typically, the received 
information includes information about orders (through the indications module 216) and 
orders (through the negotiation module 218) that the ETM 1 10 receives from other 
traders or trading institutions. The trader uses the EIM 318 to enter into and transact 
negotiations to buy and/or sell securities through the ETM 110. 

[0053] The network 3 1 4 connects the workstations 3 1 0 to the OMS 312 and to 
external networks such as the network in communication with the ETM 1 10. The 
network 314 can utilize any networking technology that supports bi-directional transfer 
of data among the OMS 312, workstations 310, and external networks, hi a typical 
embodiment, the network 314 is a private local area network (LAN) installed at a 
financial institution and interfacing with one or more external gateways. In alternate 
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embodiments, the network may be wireless, connect devices over a wide area, and/or at 
least partially carry data over a public network (such as the Internet). Other network 
components, such as a firewall, may also be present. Those of ordinary skill in the art 
will recognize that many different types of networks can perform the functionality 
described herein. 

[0054] The OMS 3 12 is preferably comprised of one or more computer systems for 
executing and maintaining an order management system. The OMS 312 receives 
instructions from the workstations to create, modify, and/or delete orders and updates the 
database 1 14 accordingly. Software providing the functionality of the OMS 312 is well 
known in the art. Commercial OMS software packages are available from The 
MacGregor Group, Eze Castle Software, Advent Software, and Decalog, to name but a 
few. In addition, some trading institutions utilize custom OMS software. 

[0055] As described above, the database 114 holds data representative of open, 
contemplated, or completed orders to buy and/or sell securities. FIG. 4 is a diagram 
illustrating a data record 400 stored in the database 1 14 to identify an order according to 
one embodiment of the present invention. Different OMS systems utilize different order 
data records and, therefore, it should be understood that FIG. 4 illustrates only one 
possible data record. However, many OMS systems store the same general information 
and the illustrated order data record 400 is intended to represent a typical order data 
record for an OMS system. 

[0056] The order data record 400 has multiple fields, each field holding different 
information about an order. The Order ID field 410 preferably holds a value uniquely 
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identifying the order associated with the data record 400. Similarly, the Trader ID field 
412 preferably holds a value uniquely identifying the trader or other person who placed 
the order. The Order Status field 414 identifies whether the order is open, contemplated, 
completed, canceled, or any other possible status. The next field, Order Last Update 
Time 416, preferably holds a timestamp that identifies the last time that the data record 
400 was modified in any way. This field 416 is useful for determining whether the most 
recent version of the data record 400 has been considered. 

[0057] The Transaction Type field 418 preferably indicates whether the data record 
400 corresponds to an order to buy or sell a security. The Security Symbol field 420 
preferably uniquely identifies the security to be transacted. The Security Symbol field 
420 can hold, for example, a Committee on Uniform Securities Identification Procedures 
(CUSIP) number, a ticker symbol, or any other identifier of the security. The Security 
Type field 422 is preferably used to interpret the other data in the data record 400 
according to the given security type. For example, treasury bills are priced in terms of a 
discount to face value; inherent in the pricing formula is the yield that would be obtained 
if the bill were held to maturity. In contrast, equity securities are priced in actual per- 
share values. The information in the Security Type field 422 can also be used to filter out 
certain types of securities. 

[0058] The Order Type field 424 preferably indicates whether the order is a market or 
a limit order, although the field can also indicate other order types. If the order is a limit 
order, the Limit Price Field 426 preferably identifies the price set by the trader. 
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[0059] The Total Order Size field 428 preferably identifies the actual number of 
shares that the trader desires to transact. The Quantity Placed Elsewhere field 430 is a 
value either equal to or less than the value in the Total Order Size field 428. In an 
embodiment of the present invention, the ETM 1 10 uses the values of these two fields 
428, 430 to determine a quantity of a security, if any, that are available to be transacted 
by the ETM. 

[0060] Preferably, the OMS 312 allows for the possibility that trading a large 
quantity of a given security may occur over several days at several different venues. For 
example, to fill an order to buy 1,000,000 shares of IBM, a trader may need to place an 
order for 300,000 shares with one broker, and record numerous executions of portions 
thereof until the full 300,000 shares placed with that broker are purchased. If the broker 
cannot provide additional shares at a suitable price, the trader may then place an 
additional quantity, up to the 700,000 shares remaining to be purchased, via another 
broker, electronic marketplace, or other venue. Preferably, the broker enters a placement 
record into the OMS database 1 14 to indicate that the trader anticipates executing a 
portion of the order through the second venue. This second venue may also fill the 
quantity it was asked to provide in several executions. Thus, an order can have one or 
more placements and each placement can have one or more executions associated with it. 

[0061] FIG. 5 is a diagram illustrating a placement record 500 preferably stored in the 
OMS database 1 14 to indicate a placement of an order at a particular venue. The Order 
ID field 510 preferably holds a value that uniquely identifies the order associated with the 
placement. The Order ID field 510 ties the placement information to the overall order. 
Thus, all placements for the same order preferably have the same value in this field 510. 
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The Broker field 512 preferably contains an alphanumeric value identifying the venue 
associated with the placement record. Lastly, the Quantity Placed with Broker field 514 
preferably lists the portion of the total order size that is placed for fulfillment through the 
venue. 

[0062] When a transaction is executed in a specified venue, such as the ETM 1 10, a 
corresponding execution record is preferably stored in the OMS database 1 14. FIG. 6 is a 
diagram illustrating an execution record 600 according to an embodiment of the present 
invention. An execution ID field 608 preferably holds a value identifying the particular 
execution. As before, the Order ID field 610 preferably holds a value that uniquely 
identifies the order associated with the execution and all executions for the same order 
preferably have the same value in this field 610. The Broker field 612 preferably 
contains an alphanumeric value identifying the venue that performed the execution. The 
Quantity Executed field 614 preferably specifies the number of securities transacted in 
this execution while the Price field 616 specifies the price at which the securities were 
executed. The Timestamp field 618 preferably records the time at which the execution 
took place. 

[0063] The OMS interfacing module (OM) 320 is in communication with the OMS 
database 1 14 via the network 314 or a direct connection. In alternative embodiments, the 
OIM 320 is in communication with the OMS 312 and/or the workstations 310. The OM 
320 is also in communication with the ETM 1 10 via an external gateway or some other 
form of network connection. In another alternative embodiment, the OIM 320 is 
integrated into the ETM 110 and is remote from the OMS 312, although some 
functionality is present at the OMS in order to provide OMS data to the OIM. 
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[0064] In a preferred embodiment, the OIM 320 includes a computer system storing 
and executing software for performing the functionality described herein. In an 
alternative embodiment, the OIM 320 executes on the same computer system as the OMS 
312. In one embodiment, the OIM 320 includes an OMS database interaction module 
322 for interacting with the OMS database 114. The OMS database interaction module 
322 reads records stored in the OMS database 114 and, in a preferred embodiment, 
creates and modifies data records stored in the OMS database 1 14. In one embodiment, 
the OMS database interaction module 322 directly accesses the OMS database 1 14 and in 
another embodiment it sends commands to an applications programming interface (API) 
in the OMS 312 for accessing the database. 

[0065] The OIM 320 also preferably includes an ETM communication module 324 
for communicating with the ETM 1 10. In one embodiment, the ETM communication 
module 324 automatically provides selected data records in the OMS database 1 14 to the 
ETM 110 and, in a preferred embodiment, receives data and/or instructions from the 
ETM. In addition, the OIM 320 also preferably includes a data record conversion module 
326 for modifying the format of the data records sent to and/or received from the ETM 
1 10 and a filtering module 238 for filtering out specified orders by security type, security 
name, order type, order quantity, order price, or some other factor or category, so that 
filtered orders are not transmitted to the ETM. 

[0066] FIG. 7 is a flow diagram illustrating actions performed by an embodiment of 
the present invention when a trader logs on to the ETM 110. Although the actions of 
FIG. 7 and subsequent figures are attributed herein to the OIM 320, one of ordinary skill 
in the art will recognize that all or some of the actions can be carried out by other entities. 
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[0067] Preferably, the OIM 320 waits 710 until a trader logs on to the OMS 312 
before transmitting data records for that trader to the ETM 1 10. In one embodiment, the 
ETM 110 sends a message to the OIM 320 when a trader at the institution in which the 
OIM 320 resides logs into the ETM. The OIM 320 interprets this message as a sign to 
commence receiving orders. In other embodiments of the present invention, the OIM 320 
uses other techniques, such as querying the OMS database 1 14 for specific entries, 
listening for an inter-process message sent by the OMS 312, polling individual trader 
workstations 310, or implementing a timer-based algorithm, to determine that a trader has 
logged on to the OMS 312. 

[0068] Once a determination 710 is made that a trader has logged on to the OMS 312 
the OIM 320 retrieves 712 data records about orders suitable for transmission to the ETM 
from the OMS database 1 14. In one embodiment of the present invention, all open orders 
are suitable for transmission to the ETM 1 10. In other embodiments of the present 
invention, the OIM 320, through the filtering module 328, makes the determination of 
suitable orders based on other criteria, such as the security type (e.g., stock or bond), 
security name (e.g., IBM or T), order type (e.g., market or limit order), order quantity, 
and/or order price. 

[0069] If necessary, the data record conversion module 326 within the OIM 320 
preferably converts 714 the data records retrieved from the OMS database 114 into a 
standardized format understood by the ETM 110. As described above, the functionality 
of the data record conversion module 326 can also be performed by the ODIM 212 in the 
ETM 1 10. Alternative embodiments of the present invention may send the data records 
individually or in multiple batches. The data transmitted to the ETM 110 depend on 
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factors such as the types of securities being traded, and/or the fields required in order to 
accurately trade such securities. 

[0070] FIG. 8 is a flow diagram illustrating the actions performed by an embodiment 
of the present invention after a trader has logged on to the OMS during the trading day. 
The actions of FIG. 8 are preferably automatically performed multiple times during the 
trading day. Initially, the OM 320 determines 810 whether the contents of the OMS 
database 1 14 have changed. The OIM 320 can perform this step by, for example, polling 
the database 1 14 at regular, near-real-time intervals, querying the database for contents of 
specified fields such as timestamps, and/or listening for network or specific interprocess 
communication message traffic. 

[0071 ] If the database has changed, the OIM 320 preferably determines whether the 
change should be transmitted to the ETM 1 10. Because typical OMS's are complex and 
multi-featured, and because securities of types not handled by the ETM 1 10 may be 
traded using the OMS 312, some changes to the OMS database 1 14 do not necessitate a 
transmission of updated data to the ETM 110. Thus, the OIM 320 determines 812 
whether the change to the database 1 14 reflects a new order of a type that is traded in the 
ETM 110. If so, then the OIM 320 retrieves 816 the pertinent data for the order from the 
database 1 14. If the change does not reflect a new order, then the OIM 320 preferably 
determines 814 whether the database change pertains to a modification of an existing 
order that has already been sent to the ETM 110. If so, the OIM 320 retrieves 8 1 8 the 
data records corresponding to the modified order from the database 114. Once the 
appropriate data records, if any, are retrieved from the database, the OIM 320 preferably 
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converts 820 the data records into the appropriate format and transmits the records to the 
ETM 1 10 as described above with respect to FIG. 7. 

[0072] FIG. 9 is a flow diagram illustrating the actions performed by an embodiment 
of the present invention when the OMS database 1 14 is updated in response to a trade 
executed by the ETM 110. The illustrated steps can be performed each time a trade is 
executed, or in batch. However, the steps are preferably performed frequently enough so 
that the OMS database 1 14 is updated in substantially real-time. 

[0073] The OIM 320 initially determines 910 whether an execution occurred in the 
ETM 110 involving an order in the OMS 312 associated with the OIM. The step may be 
performed, for example, by receiving a message from the ETM 110 identifying a 
particular execution that occurred at the ETM, by filtering a list of all executions or other 
data from the ETM for executions listed in the OMS 312, or by periodically polling the 
ETM for performed executions. 

[0074] If an execution occurred in the ETM 1 10 involving an order in the OMS 312 
associated with the OIM 320, the OIM receives 912 information from the ETM 
describing the execution. This information includes, for example, the type, amount, and 
price of securities traded, the time of execution, and/or information identifying the 
original order in the OMS database 1 14 on which the execution was based. The OIM 320 
converts 914 the received information about the execution into the format used by the 
OMS 3 12. Then, the OIM 320 updates 916 the OMS database 114 with the converted 
execution data. As a result of these steps, the OMS 312 is updated automatically and 


24 


22172/05507/SF/5035215.4 


Case 5507 Patent 

transparently to reflect executions performed at the ETM 1 10. The executions appear to 
the OMS 312 as typical trades conducted at another broker. 

[0075] In summary, the present invention includes an electronic trading marketplace 
that generates liquidity, at least in part, by receiving order information directly from the 
databases of OMS systems at trading institutions. Since orders are extracted from the 
OMS databases automatically, and information about executed orders is inserted into the 
databases automatically, the OMS databases "see" the marketplace as "just another 
market intermediary." Moreover, traders are able to conduct trades in the electronic 
marketplace without any duplicative manual efforts. 

[0076] The above description is included to illustrate the operation of the preferred 
embodiments and is not meant to limit the scope of the invention. The scope of the 
invention is to be limited only by the following claims. From the above discussion, many 
variations will be apparent to one skilled in the relevant art that would yet be 
encompassed by the spirit and scope of the invention. 
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